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PREFACE 


The purpose of this document is to provide a brief report on a SHARP 
portability studies task conducted for, and funded jointly by, the NASA 
Solar System Exploration Division's Voyager Project and for the 
Telescience Testbed Program managed by NASA Ames Research Center. It 
is intended as a companion document to an additional report called "A 
Report on SHARP and the Voyager Neptune Encounter" (JPL Publication 90- 
21) which describes the development and application of the Spacecraft 
Health Automated Reasoning Prototype (SHARP) for the operations of the 
telecommunications system and link analysis functions in Voyager 
mission operations. This report is intended primarily for technical and 
program managers in the area of mission operations automation for 
spacecraft and telescience applications, and describes some specific 
progress on the portability studies for the JPL Space Flight Operations 
Center, plans for technology transfer, and potential applications of SHARP 
and related artificial intelligence technology to telescience operations. 
The companion report provides an overview of the design and functional 
description of the SHARP system as it was applied to Voyager. 

The application of SHARP to Voyager telecommunications was a proof-of- 
capability demonstration of artificial intelligence as applied to the 
problem of real-time monitoring functions in planetary mission 
operations. SHARP has provided us with an excellent example of how 
advanced artificial intelligence techniques can be smoothly integrated 
with a variety of conventionally programmed software modules, as well 
as guidance and solutions for many questions about automation in mission 
operations. From a broader, operational perspective, SHARP has shown 
that a large set of mission operations functions in the area of real-time 
monitoring of spacecraft health and status can be effectively automated, 
with significant payoffs in the areas of safety, work-force savings, 
personnel productivity, and system reliability. These payoffs are 
discussed in the companion report. 

SHARP has received widespread attention in the press, ranging from mass 
news media to highly technical journals. News articles about SHARP have 
appeared in Information Week Magazine, Al Week, Computerworld, 
Computers and Physics Journal, Federal Computer Week, Symbolics 
Symposium, IEEE Expert, IEEE Spectrum, Government Executive Magazine, 
Insight, Aerospace Engineering, The Washington Times, The New York 
Times, The Los Angeles Times, Nikkei Artificial Intelligence (Japanese 
publication), and the Journal of Commerce. While this level of attention is 
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certainly exciting, it also indicates the importance that both 
technologists and users are attaching to effective applications of 
artificial intelligence. 

The SHARP application to Voyager telecommunications was conducted as 
part of a long-term research and development task being conducted for the 
NASA Office of Aeronautics and Exploration Technology (OAET) Artificial 
Intelligence Program called "Ground Data Systems Automation." This task, 
which began in October 1987, has the on-going objective of developing and 
demonstrating automation technologies which enable and enhance 
multimission capabilities of operations ground systems for planetary 
spacecraft and for the Deep Space Network (DSN). 

Currently, under joint sponsorship of the NASA OAET Artificial 
Intelligence Program and JPL Flight Projects Support Office, a SHARP 
"shell" is being readied for transfer to the Space Flight Operations Center 
(SFOC) in the summer of 1990, where it will be used beginning in August 
for the Magellan spacecraft's telecommunications operations. At that 
time, the SHARP shell will be fully compatible with the SFOC 

environment, meet SFOC user interface and data interface requirements, 
and be in compliance with JPL software standards for flight software. 
This shell will be a major component of a multimission spacecraft 

performance analysis tool set which the Flight Project Support Office 
will develop. Additionally, the JPL Deep Space Network's Office of 
Engineering is applying SHARP technology to telecommunications link 
performance analysis as part of the Network Operations Control Center 
(NOCC) upgrade, scheduled for operations in 1991. 

With the success of the application for Voyager telecommunications, and 
follow-on tasks under way which will carry the technology forward into 
operational systems, we feel that the major objectives set for SHARP 

have been achieved and that there are now opportunities for multiple 

applications of artificial intelligence in planetary mission operations and 
telescience operations of the future. 


David J. Atkinson 
JPL, April 4, 1990 
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ABSTRACT 


This document provides a report on a SHARP portability study. It describes 
some specific progress on the portability studies for the JPL Space Flight 
Operations Center, plans for technology transfer, and potential 
applications of SHARP and related artificial intelligence technology to 
telescience operations. 

The application of SHARP to Voyager telecommunications was a proof-of- 
capability demonstration of artificial intelligence as applied to the 
problem of real-time monitoring functions in planetary mission 
operations. A companion report (JPL Publication 90-21) provides an 
overview of the design and functional description of the SHARP system as 
it was applied to Voyager. 
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1 . Overview of Code EC/EL FY89 Activities 


Work on SHARP in fiscal year 1989 under funding from Codes EC and 
EL was aimed at achieving the following two objectives: 

1. Help achieve compatibility for SHARP with SFOC. 

2. Help achieve portability of SHARP to SFOC and other 
computing environments such as those which might be part of 
a telescience application. 

These objectives were addressed through the following activities: 

1 . Providing a preliminary plan for a complete porting of SHARP 
to an SFOC environment and delivery to a baseline SFOC. The 
plan addresses/includes: 

• Close integration with SFOC over the long term. 

• Plans for modifications to SHARP for portability, 
maintainability, and performance. 

• Plans for the delivery of hardware, testing, 
documentation, and training. 

• Schedules for development and integration which mesh 
with SFOC and flight project user requirements. 

2. Participating in the SFOC user-interface requirements 
working group. 

3. Demonstrating the performance of some of the significant 
modules of SHARP on an SFOC-compatible SUN workstation 
with Symbolics Ivory board installed. 

4. Evaluating the performance of the ported modules, including 
profiles of CPU time, memory requirements, file system 
access, and other measurements. 


The next section of this document gives a summary of SHARP and its 
use during the Voyager encounter with Neptune. This is followed by 
sections that expand on the set of activities described above. 
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The document concludes with some remarks on how SHARP can 
support scientific instrument monitoring and, more generally, how 
Al technology can support telescience. 
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2. Overview of SHARP and the 

Voyager-Neptune Demonstration 

The Spacecraft Health Automated Reasoning Prototype (SHARP) 
introduces automation and artificial intelligence technologies to the 
process of monitoring spacecraft operations. One of the goals of 
SHARP is the elimination of much of the mundane processing and 
tedious analysis currently required of operations personnel. Another 
goal is to provide faster and more reliable identification of errors 
that occur during a spacecraft mission than is currently available. 
The major automated functions provided by the SHARP system 
include: 

• Real-time anomaly detection and diagnosis; 

• Visualization of channelized data and system status; 

• Acquisition and centralization of operations data in a single 
workstation, including real-time spacecraft and ground 
system engineering data, sequence of events, and alarm 
tables; 

• Real-time analysis of spacecraft performance predictions; 

• Integration with specialized numerical analysis software, 
e.g., fast Fourier transforms for determining spacecraft 
antenna pointing accuracy. 

The SHARP prototype was developed for use in the Voyager 
telecommunications (telecom) monitoring area. The SHARP system 
provides telecom personnel with an environment that allows them to 
have a more complete understanding of how the telecommunications 
link is functioning between a spacecraft and the Deep Space Stations 
(DSS). Deep Space Station sites are located at Goldstone, California, 
Madrid, Spain, and Canberra, Australia, and collectively form the 
Deep Space Network (DSN). 

The SHARP environment contains the necessary data to allow SHARP 
to oversee the expected behavior of the spacecraft and Deep Space 
Stations it is monitoring. It also receives real-time data which 
reveal how these systems actually are performing. If the real-time 
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data fail to correlate with the expected behavior, SHARP informs the 
operator responsible for the monitoring operation that an alarm 
condition exists. It also lists the potential causes for this anomaly 
and suggests what actions to take to respond to the alarm condition. 
In SHARP, the automation of fault detection and diagnosis is 
accomplished through the use of artificial intelligence programming 
techniques. Artificial intelligence techniques are distributed 
throughout all components of the SHARP system. Artificial 
intelligence programming methodologies have enabled more 
effective automation and thorough analysis by SHARP functions. 

In addition to having complete access to all of the relevant data 
which allow SHARP to perform its necessary analysis functions, the 
SHARP system contains an extensive collection of graphical 
displays. These displays give the operations personnel a 
comprehensive view of the status and dynamics of the systems that 
they are monitoring. 



Figure 1. SHARP System Overview 
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Figure 1 illustrates a top-level view of the SHARP system. Shown 
are the individual modules that compose the system, as well as 
relevant components that are external to the Voyager application of 
SHARP. SHARP is implemented in Common Lisp on a Symbolics 3650 
color Lisp Machine. The system is currently being ported to a Sun 
workstation, also running Common Lisp. SHARP relies extensively on 
an expert system building language called STAR*TOOL, developed at 
JPL. 

2.1. Inputs 

In order for the SHARP prototype to analyze the telecommunications 
link from the spacecraft through the Deep Space Network and 
ultimately to the computers at JPL, a wide variety of information 
and data must be accessed and processed. Some data and knowledge 
are acquired before operational use and are stored in databases or 
are encoded within the SHARP program. Other data are collected in 
real time during operational use. 


The following gives a short description of the data. Figure 2 gives a 
summary of the source of each type of data, where the data are 
encoded in SHARP, and who has the capability to modify the data. 


Data 

Source 

Location 
in Sharp 

Modifiable by 

Predicts 

Univac Text File 

Database 

N/A 

ISOE 

Univac Text File 

Database 

User 

Channelized Data 

Real Time 

Database 

N/A 

Alarm Limits 

Domain Expert 

Data Tables 

User 

Rules 

Domain Expert 

Code 

Programmer 


Figure 2. SHARP Input Data 


Predicts 

These are predictions of values for spacecraft and Deep 
Space Network station parameters based on numerical models 
of system performance. 
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Integrated Sequence of Events (ISOE) 

This is a time-ordered sequence of scheduled spacecraft and 
Deep Space Station activity. Examples of these include: 
specifications regarding timing and the transmitter power 
and frequency at the Deep Space Station for uplink commands 
being sent to the spacecraft, when the spacecraft is 
performing maneuvers, and the state of the receivers and 
transmitters on the spacecraft. Last minute corrections, 
additions, or deletions to these events can be made by the 
operator. 

Channelized Data 

These are real-time engineering data that contain 
information regarding the status of systems both on board 
the spacecraft and at the DSSs. 

Alarm Limits 

These are minimum and maximum values that specify the 
boundaries of the nominal values for engineering data. Error 
conditions, i.e. alarm states, occur when the engineering data 
exceed these limits. Changes to these limits can be made by 
the operator in response to planned spacecraft state changes 
as well as unforeseen changes in the behavior of the systems 
being monitored. 

Rules 

These contain knowledge of how the various systems that 
SHARP is monitoring should behave and interact. These rules 
use that information and the data described above to 
determine the existence of either simple or complex error 
conditions, and to give hypotheses regarding the causes of 
these errors. 
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2.2. Processing 

There are several kinds of processing which occur within the SHARP 
system. These are: 

• Capturing the real-time channelized data and storing them in 
a database, 

• Using conventional and artificial intelligence techniques to 
analyze the real-time data for the occurrence of alarm 
conditions, 

• Determining probable causes and responses to alarm 
conditions, and 

• Displaying data and management of the various displays. 
SHARP runs in a multiprocessing environment with interactions 
among the different kinds of processing. 

2.3. Outputs 

The primary purposes of the SHARP system are to provide a better 
operational environment for monitoring various spacecraft and Deep 
Space Station systems, to warn an operator if there is an alarm 
condition in the systems that SHARP is monitoring, to assist the 
operator in determining the cause of an alarm, and to suggest 
actions to take in response to an alarm. The means used to 
communicate this information consist of a number of displays, each 
designed to handle a specific task. Secondarily, SHARP also stores 
the results of some of its processing in log files and databases. 
SHARP is not an autonomous system in that it takes no control 
actions of its own. A human is “in the loop” at all times. 

The displays of SHARP provide access to data resident in the 
system, provide an interface to allow the operator to change that 
data when appropriate, and dynamically indicate alarms and what 
systems are affected by them. The displays are summarized in 
Figure 3 and the text that follows. 
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Display Name 

Functionality 

Alarm Warnings 

Attitude and Articulation Control 
Block Diagrams 
Channelized Data Plots 
Fast Fourier Transform 
Link Status 
Alarm Meters 

Indicate System Status 
and Alarm Conditions 

Alarm Limit Tables 
Integrated Sequence of Events 

Display Data and Accept 
User Modifications 

Channelized Data Monitoring 
Predicts 
Alarm History 

Show Data or SHARP 
Status Information 


Figure 3. SHARP Displays 


Alarm History 

This is a scrolling text display that shows all warnings given 
by SHARP during a session. 

Alarm Limit Tables 

This is a tabular display that presents the operator with the 
values of the alarm limits. The operator can modify alarm 
limits and other parameters using this interface. 

Alarm Meters 

This display is a collection of meters that show which 
channels are currently in alarm, and give the time of the last 
data value that caused the alarm. 

Alarm Warnings 

This is not actually a display, but a pop-up window that will 
appear whenever a warning message is given. This window 
will appear regardless of the primary SHARP display being 
viewed by the operator. 
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Attitude and Articulation Control 

This display combines spacecraft motion parameters (pitch, 
yaw, and roll) and records spacecraft movement over time in 
an iconic display of spacecraft attitude. 

Block Diagrams 

This collection of displays based upon functional schematic 
block diagrams allows the user to view the current, 
instantaneous operational state of components of the 
communication path from the spacecraft through the Deep 
Space Stations. 

Channelized Data Monitoring 

This display is primarily for the SHARP system implementors 
to allow them to examine activity regarding the real-time 
data acquisition and database transactions. 

Channelized Data Plots 

This collection of displays gives graphical views of the 
collected real-time channelized data plotted in a variety of 
formats. 

Fast Fourier Transform 

This display shows the result of a fast Fourier transform 
(FFT) computation on a selected monitor data channel. An FFT 
is computed on the signal strength of the spacecraft 
transmissions received by a Deep Space Station. By being able 
to examine the relative magnitude of one component of this 
FFT, the SHARP system helps to determine when there is an 
antenna pointing problem at the Deep Space Station that is 
tracking the spacecraft. 

Integrated Sequence of Events 

This display allows the operators to search for and review 
summaries of selected events from the Integrated Sequence 
of Events (ISOE) that affect telecom operations. It also 
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allows them to update the SHARP ISOE database to reflect 
the actual real-time commands sent to the spacecraft. 

Link Status 

This display shows Deep Space Station antenna assignments, 
uplink and downlink transmissions, and data rates for those 
transmissions. This display also helps the operators to 
predict when data quality may be degraded. In contrast to the 
block diagrams which show the instantaneous status, the 
Link Status display shows status over time. 

Predicts 

This display presents the predict information to the operator 
in a tabular form, and shows DSS view periods for the 
spacecraft in a graphical time-line format. 

2.4 Results of the Voyager-Nepture Encounter 

SHARP was evaluated by Voyager operations personnel during the 
Neptune encounter over a period of approximately 480 hours of 
operational testing. During this period, the facilities within SHARP 
helped operators find the cause of, and solve, a Voyager science data 
error anomaly which appeared in the telemetry from the spacecraft 
as an excess error count. 

The general nature of the response from operations personnel during 
this testing period was very positive. It reinforced the perception 
that technologies such as SHARP can give value and benefit to 
spaceflight operations. 
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3. Transferring SHARP to JPL's 
Space Flight Operations Center 

A team comprising SFOC and SHARP developers has prepared a 
conceptual plan for the integration of SHARP technology into SFOC. 
Under this concept, the SHARP system would be phased into the SFOC 
environment, thereby achieving the dual objectives of quick 
availability of the technology within SFOC and an ultimate 
"harmonious" integration. The focus was on the technical issues 
involved to demonstrate the feasibility of introducing SHARP into 
SFOC, Topics such as requirements of specific flight project 
applications, schedules, and costing were deferred. 

Further study indicated that it is convenient to consider SHARP in 
two parts. The first part effectively constitutes a reusable "shell" 
or "skeleton." It consists of those portions of SHARP that are 
essentially independent of the particular subsystem being 
monitored. The second part consists of the application-specific 

knowledge for a particular subsystem of a particular flight mission. 
This latter part is less sensitive to the environment and platform 
used to support SHARP. 

During the Voyager encounter with Neptune, the SHARP developers 
concluded that the Genera operating system is insufficiently 
responsive for the operational use of SHARP, particularly with 
respect to displays. They decided to reimplement the user interface 
using a more efficient, more portable graphics kernel. This effort is 
in progress as part of the continued SHARP development. 

Although long range plans for SHARP application continue to evolve, 
two specific work units have been identified, funded, and planned. 
The "SHARP Technology Transfer" effort will deliver SHARP to the 
SFOC environment. The "Application of Automated Spacecraft Health 



Monitoring" effort will apply SHARP to monitoring the Magellan 
telecommunications subsystem as an operational demonstration. 

The SHARP Technology Transfer work unit will initiate the process 
of making the technology embodied in SHARP available for support of 
space flight operations. Specific objectives are to: 

1. Provide expert system capabilities for monitoring spacecraft 
health in the SFOC environment in a manner that utilizes 
SFOC data sources and operates gracefully with other SFOC 
features. 

2. Achieve levels of robustness and operability required for 
operational software and comply with appropriate SFOC and 
JPL standards for deliverable, software-intensive systems. 

3. Prepare for subsequent application of SHARP to 

telecommunications link performance analysis for Magellan 
and Galileo, for performance monitoring of other types of 
spacecraft subsystems, and for potential support of the 
Engineering Analysis Subsystem Environment (EASE). 

The approach will be to modify and enhance the existing SHARP 
Voyager Telecommunications Subsystem demonstration prototype to 
produce a reusable software component. The target platform will be 
workstations of the same type and operating system as those used 
by SFOC. Negotiations with the SFOC project management resulted 
in the determination that SHARP is to be integrated into SFOC's 
operational pilot environment. This is an instance of the SFOC 
system that is being established in parallel with the baseline SFOC. 
It is intended to serve as a test-bed to allow new technologies to be 
evaluated in depth prior to their inclusion in the SFOC baseline. 
Integration into the pilot environment will allow SHARP to be used 
under operational conditions with actual engineering and monitor 
data. 
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This work is in progress. It is planned to be completed in the 
summer of 1990. It is sponsored by the OAST Artificial Intelligence 
program through JPL's Knowledge Systems subprogram. 

The Application of Automated Spacecraft Health Monitoring work 
unit will further demonstrate the feasibility of shifting much of the 
burden of routine interpretation of spacecraft engineering data from 
a human operator to intelligent software. This will facilitate 
continuous monitoring without degradation of performance due to 
operator fatigue or inattention. The analysis of unusual or 
emergency conditions will be facilitated by the ability to quickly 
present the information at an appropriate level of abstraction. The 
effectiveness of monitoring will be further enhanced by providing 
each operator with access to cumulative knowledge that is 
otherwise restricted to a few experts. 

The approach will be to apply the reusable, SFOC-based version of 
SHARP to the Magellan Telecommunications Subsystem. SHARP will 
be operated in parallel with existing monitoring tools and 
procedures in support of planetary operations. 

This work is scheduled to begin in early 1990 and to be completed 
the following summer. It is part of the Mission Operations and Data 
Analysis Technology Initiative. 


1 3 



Schedule 


IFY89 
Q4 I Q1 


SHARP Technology 
Transfer 




Application of Automated 
Spacecraft Health 
Monitoring 


Long Range Planning 


Additional Applications 




■FY90 


Q2 


03 


Q4 


FY91I 
I Q1 


-(TBD) 


Conclusions 

The effort in FY90 will result in an SFOC-hosted capability for 
intelligent monitoring and diagnosis of the Magellan 

Telecommunications Subsystem. This version of SHARP will have 
the following specific characteristics: 

1. It will execute in an SFOC-compatible workstation 
environment; 

2. It will have an SFOC-compatible user interface; 

3. It will operate on SFOC-generated data; 

4. It will be sufficiently robust to be beneficial to operations. 

Once this capability is in place, it will be necessary to gain 
sufficient operational experience with it to test its accuracy and 
completeness in recognizing and diagnosing telecommunication 
system errors. 
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SHARP has the immediate potential to be applied to a broad range of 
systems that exhibit multifaceted behavior. It can be usefully 
applied to the monitoring and diagnosis of the state and quantitative 
attributes of many individual spacecraft subsystems (e.g., Attitude 
and Articulation Control, Power, and Propulsion), of individual 
instruments, and of ground and spaceborne computing and 
communications systems (e.g., the Network Operations Control 
Center and SFOC itself). With further research, it should also be 
possible for SHARP applications to cooperate and thus provide 
multiple layers of visibility into these systems. 


15 



4. General Issues In Porting SHARP to SUN/IVORY 


The purpose of this task was to port and evaluate portions of SHARP 
to a SFOC-compatible SUN workstation to help provide guidelines for 
modifications of SHARP necessary to enhance its portability and 
performance in alternative delivery environments. 

The activities for this task included: 

• The demonstration of the performance of some of the 
significant modules of the SHARP system on a SFOC- 
compatible SUN Workstation with the Symbolics Ivory board 
installed. 

• The evaluation of the performance of the ported modules, 
including profiles of CPU time and memory requirements, file 
system accesses, and other measurements to be determined. 

4.1 Discussion 

The Ivory is an add-in coprocessor board for SUN 3 and SUN 4 VME- 
based workstations that allows users to run the Symbolics Genera 
operating system within the Unix environment. The Ivory-based 
products are source-code compatible with all programs developed in 
either Common Lisp or on any Symbolics Lisp Machine. The board is 
based on Symbolics' Ivory microprocessor technology. 

Our tests were performed on a black and white SUN 3 workstation 
configured with 8MB of physical memory on the SUN processor and 
12MB of physical memory on the Ivory Lisp coprocessor. The 
Symbolics 3650 machine was configured with 24MB of physical 
memory and included a 8-bit CAD buffer II card. 

The Ivory board was evaluated by a series of tests that were 
designed to test its computational speed in the following areas: 
graphics output, file I/O, general purpose processing in the average 
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case, and raw computational throughput. The identical source code 
was run on each machine. The results of the tests are as follow: 

Test 1; Graphic s Ou tput S peed 

This test was designed to determine the speed of the graphical 
interface between the Ivory board and the SUN workstation 
running XWindows. The test involved the drawing of several 
thousand points and vectors on a black and white screen. The 
Symbolics 3650 took 2 seconds to complete the task on its 
color screen whereas the Ivory took 3 seconds on its black and 
white screen. 

It is believed that if the program were re-coded to specially 
run on the Ivory processor, the Ivory would run at least three 
to four times faster. The reason that the Ivory ran slower was 
because the graphics calls went through four levels of 
indirection before finally executing the call on the SUN 
workstation. The program could have been rewritten to require 
only two levels of indirection. 

Test 2: File I/O Processing 

This test was designed to determine the speed of performing 
file I/O on the Ivory. The test involved running the SHARP 
database storage retrieval system. 

The Symbolics 3650 took 3 seconds to complete the task 
whereas the Ivory took 8 seconds. 

The Ivory took longer to execute because all file I/O from the 
Ivory required two levels of indirection before the I/O was 
actually performed on the SUN workstation. It is not believed 
that this test could have been made to run faster by specially 
rewriting the code to run on the Ivory. 
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Test 3: General Purpose -Processing 

This test was designed to determine the speed of performing 
general purpose Lisp processing on the Ivory. This test 
involved running an existing Al program called STAFTTOOL. 
STAFTTOOL contains more than one-hundred thousand lines of 
Common Lisp code. Several STAR*TOOL programs were used 
for the test. Each test tried various capabilities of the 
STAR*TOOL system while also checking for correct results. 

The Symbolics 3650 took 8 seconds to complete the task 
whereas the Ivory took 25 seconds. 

Test 4: Raw Computational Throughput 

This test was designed to determine the raw computational 
throughput of the Ivory. The test ran exclusively within the 
cache of the Ivory without generating any page faults to 
expose the difference between general purpose processing and 
raw throughput. This test consisted of the execution of a 
series of loops whose bodies were simple math operations. 

The Symbolics 3650 took 20 seconds to complete the task 
whereas the Ivory required 73 seconds. 

The Ivory processor lived up to its claims of being 100% source-code 
compatible with the Symbolics product line. Between all the tests, 
over 150,000 lines of Lisp code were recompiled to run on the Ivory 
coprocessor without any errors. 
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4.2 Conclusion 

The overall conclusion drawn from the four tests is that the Ivory 
processor running on a SUN workstation runs about 2.7 times slower 
than a Symbolics 3650 Lisp Machine. 

In the near future we will also be running the identical tests on a 
MAC llx configured with an Ivory board. We are told that the MAC 
Ivory runs much faster than a SUN Ivory because of a larger cache on 
the MAC Ivory board. 

The implications of this result are that the SUN Ivory combination 
does not provide the necessary hardware performance to run SHARP 
and provide the necessary real-time analysis of data. However, 
initial tests have shown that if SHARP were translated to run 
directly in a SUN 4 native operating environment (without 
translating SHARP from Common Lisp) that it would run several 
times faster than its Symbolics 3650 version. We feel this is the 
solution to take. 
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5. Future Work 

5.1 SHARP for Instrument Monitoring and Telescience 

The utility of the SHARP system as a monitoring and diagnosis 
workstation was demonstrated for the Voyager telecommunications 
subsystem during the Neptune encounter during August 1989. SHARP 
has been designed from the outset for multimission and 
multisubsystem applicability in consonance with the charter for 
JPL's Space Flight Operations Center. 

A potential application area for SHARP is the monitoring of 
scientific payloads -- both specific experiments and the 
communications links required to support telescience. SHARP 
provides a diverse set of capabilities for monitoring science 
activities on platforms such as Space Station Freedom, the network 
of satellites envisioned in the Earth Observing System, and remote 
ground sites like Greenland and Antarctica. These capabilities 
include: predict generation, dynamic alarm limits, sequence of 

events browsing, real-time channelized data display and analysis, 
system-level status monitoring, real-time knowledge-based fault 
diagnosis and recovery advice, continuous supervision, a graphics- 
oriented user interface, and specialized analysis functions. 

Using SHARP to support telescience would provide the benefits of 
increased reliability regarding the scientific research being 
conducted and the instrumentation supporting that research. There 
could also be increased productivity by the individuals monitoring 
the experiment. 

SHARP, used by an investigator to remotely monitor a scientific 
experiment, would be able to follow the progress of the experiment 
in terms of the experimental protocol being used and the scientific 
data being generated. SHARP could receive engineering sensor data 
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from the equipment necessary to run an experiment and determine 
whether it matched expected operational performance. For example, 
SHARP could monitor the output voltage and current on a power 
supply to determine if it had been turned on at the appropriate time 
and if it was delivering the proper value of power as specified by an 
experimental protocol. If the measured data did not agree with the 
operational plan, the scientist could be alerted by SHARP to this 
discrepancy. SHARP could also receive science data from equipment 
that was monitoring the result of an experiment. If the scientist 
perceived that the experiment was not progressing well, he could 
change the experimental protocol in response to that information. 
Finally, if SHARP were programmed with the knowledge of the 
protocol and the expected results of an experiment, it could reason 
about either the engineering data or the science data being received. 
This capability would allow the experiment to be monitored by an 
operator with less knowledge about its behavior, freeing the primary 
investigator for more important tasks. However, the safety would 
not be impaired as SHARP would be able to alert the operator of 
anomalous behavior and to give the operator recommendations of 
potential responses to the anomalies. 

Many experiments require constant supervision to guarantee that 
they progress normally. If such an experiment were placed on board 
the Space Shuttle or Space Station Freedom, it might require an 
astronaut to do this supervision. This effort would take valuable 
time away from other activities that the astronaut could be 
performing. A scientist on the ground, monitoring the experiment 
remotely with the assistance of a SHARP system, would free the 
astronaut to do other tasks. 
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5.2 Other Al for Telescience 


SHARP shows potential for helping to increase the amount of 
scientific return that can come from space exploration and 
telescience. Two other areas of investigation within the Artificial 
Intelligence Group at JPL could complement SHARP and also increase 
the knowledge gained from endeavors in telescience. These are in 
the fields of scheduling and scientific data analysis. 

Al technology can support telescience in scheduling and resource 
allocation for scientific experiment operations. There is often a 
need to reconfigure an experiment within a short time frame due to 
unexpected results, transient opportunities, or changes in onboard 
resources to support the experiment. The Al Group at JPL has 
developed an automated scheduling system known as Operations 
Mission Planner (OMP). This system is based on interleaved, 
iterative refinement and heuristic control of search and was 
inspired by observing Voyager mission specialists. OMP was 
designed to address the goal of handling unexpected events with 
minimal disruption to an existing schedule. Research results from 
the OMP task currently are being transferred to Space Station 
Freedom scheduling domains in collaboration with Johnson Space 
Center. The goal in this work is to combine autonomous scheduling 
with interactive scheduling tools to provide an automated 
scheduling capability which can be invoked and guided by ground- 
based operations personnel. This capability is applicable to remote 
configuration/reconfiguration of spaceborne scientific experiments. 

Another area where Al-based techniques can support telescience is 
data analysis. JPL's Al Group also is working on a task known as 
Scientific Analysis Assistant (SAA) which addresses the storage, 
manipulation, analysis, and visualization of scientific data. Some of 
the specific objectives of this task include developing a data 
manipulation and presentation language to allow the investigator to 
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access and perform transformations on data and present it in an 
informative format, providing an integrated toolbox of Al-based 
analysis and simulation tools, and developing an intelligent library 
facility for the storage and retrieval of analysis functions. Longer- 
term objectives include providing a capability for flexibly 
composing and/or creating data filters for abstracting large 
volumes of data, and the use of user modeling techniques to infer 
investigators' analysis goals so that the SAA may suggest related 
data sets and appropriate analysis tools. The goal of this work is to 
provide scientist users with desktop, graduate-student level 
assistance in analyzing and interpreting data from remote scientific 
instruments. 
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